The present invention relates to name services, and in particular, to managing access to and the size of a name service.
In a distributed computer system, a multitude of applications cooperate with each other to provide a set of services to clients. To cooperate with each other, applications may need information about each other. Such information may include configuration data, such as port configuration data, and system load data. For example, a business application provides confidential pricing information to users. Before a user is permitted to receive the information, the user logs on to the business application, supplying to the application a password and a user name. To authenticate the user, the business application transmits to an authentication server an authentication request that includes the password and usemame. The authentication server uses the password and user name to determine whether the user is authorized to receive the pricing information. To cause an authentication server to verify whether a user is authorized, the business application needs certain information about other services. In particular, the business application needs information about who provides authentication services, which port to transmit an authentication request to, and whether the authentication service is currently accepting requests.
One technique for providing such information uses a xe2x80x9cname servicexe2x80x9d. A name service is a computer component (e.g. a set of processes) dedicated, at least in part, to registering information received from clients and providing information to clients that request the information. Clients who register information with a name service or who request registered information are referred to as name service clients. A name service allows a name service client to make information available to other name service clients. To make information available to name service clients, a name service client transmits a publication request to a name service. A publication request is a request to make information available to a set of name service clients that request the information. A name service client who issues a publication request is referred to as a publishing client. Typically, the publication request includes a key and data associated with the key. The data associated with the key is referred to as published data because once a name service receives the published data and the associated key, the name service returns the data to any name service client requesting data associated with the key. Making data available in this manner is referred to as publishing the data.
For example, upon initialization, an authentication server transmits the string xe2x80x9cPORT=1560xe2x80x9d along with a key xe2x80x9cAUTH-SERVER-Axe2x80x9d to associate with the string. The business application, needing to know to what port to submit an authentication request, queries a name service. Specifically, the business application requests published data associated with the key xe2x80x9cAUTH-SERVER-Axe2x80x9d. In response, the name service returns the published data xe2x80x9cPORT=1560xe2x80x9d.
Typically, when a name service receives a publication request, it creates a name entry which associates the specified key with the specified published data. Over a period of time, a name service receives numerous publication requests, and creates name entries that associate the received published data with their corresponding keys. Overtime, the number of name entries can become unwieldy, many of them being stale, that is, no longer needed or valid (xe2x80x9cstalexe2x80x9d).
One technique for preventing the number of name entries from becoming unwieldy and to eliminate stale entries is referred to as the cooperative technique. Under the cooperative technique, the publishing client responsible for creating entries is responsible for deleting them, by, for example, requesting that the name service delete them.
Unfortunately, the cooperative approach is subject to certain types of errors. First, a computer malfunction may prevent the publishing client that created a name entry from deleting the name entry. Second, the publishing client may not delete an entry it creates simply because it is not configured to do so. Finally, two or more publishing clients may use the same key. Thus, when a first publishing client issues a publication request that includes the key xe2x80x9cSAME KEYxe2x80x9d, the key is associated with the published data specified by the request. When a second publishing client issues a second publication request that includes xe2x80x9cSAME KEYxe2x80x9d, the name service may overwrite the previous entry, and associate xe2x80x9cSAME KEYxe2x80x9d with the published data specified in the second request.
Because the name service depends on clients to delete a name entry they cause to be created, and those clients may not request the deletion of the entry, the number of name entries may become unwieldy if the name service relies solely upon the cooperation of the publishing entity. Thus, name services that use the cooperative technique also have a mechanism for removing entries when they are so xe2x80x9coldxe2x80x9d. Because it is possible that even old entries may not be stale, the name service applies age criteria that removes entries that are so old that their age leaves little risk that they are not stale. Unfortunately, under such age criteria, many stale entries persist, wastefully occupying memory with data that is not used.
Based on the foregoing, it is desirable to provide a method of deleting information in a name service soon after it is no longer likely to be needed, and to prevent entities from inadvertently overwriting entries created by other entities.
A method and mechanism for managing a name service is described. The name service described herein includes published data that is associated with one or more duration entities and one or more modification entities. By associating name entries with a duration entity and a modification entity, the name service is able to more efficiently manage access to published data and the amount of memory needed to store it. To publish data, a publishing client transmits a publication request to a name service. The publication request may specify a modification entity and a duration entity. The name service creates at least one name entry that associates the published data with the modification entity and the duration entity.
According to another aspect of the present invention, there are several requests to modify or depublish published data that a name service will honor only when they originate from a modification entity. These are (1) requests to modify published data, and (2) requests to depublish published data.
According to another aspect of the present invention, a name service depublishes published data based on the termination of the duration entity that is associated with the published data. For example, a garbage collector detects when the duration of an entity ends. The garbage collector transmits a message to the name service to indicate that the entity has terminated. In response, the name service depublishes the published data for which that entity was the designated duration entity.
According to another aspect of the present invention, name service recovery is performed on a system failure. The remaining name service daemons delete each non-local entry from the local replicated name entries and transmit broadcast publication requests for local name entries to the other surviving name service daemons.
According to another aspect of the present invention, a name service may persistently store name entries. Thus, when the name service is restarted, it may continue to provide the persistently stored name entries to those clients requesting the name entries. Persistent name entries are not depublished during name service recovery. They are explicitely modified or depublished by a modification entity.